home *** CD-ROM | disk | FTP | other *** search
- I've noticed a **lot** of network traffic about delays that are encountered
- while using Trumpet winsock. As the developer of the VT Socket VBX I've
- had to spend a lot of time looking at the interactions between Trumpet
- and its callers. Trumpet gets blocked when a number of short sends are
- issued in rapid succession. This happens most frequently during telnet
- or similar sessions, where a send is issued for each key stroke.
-
- When using Trumpet in blocking mode (the default), it just looks like it
- went to sleep for awhile. When using with WSAAsyncSelect however, this
- causes WSAEWOULDBLOCK and WSAEINPROGRESS errors. To avoid these errors,
- I've added "while(WSAIsBlocking()) YieldToOthers();" to my code. This
- mostly works, but sometimes Trumpet never breaks out of this loop. How
- do I know? Because a Trumpet trace of the socket calls shows the call
- being repeated over and over--forever.
-
- My suspicion at this point is that Trumpet depends on Windows message
- handling to drive its internal code. If there are no messages or
- interrupts, it appears that it just sits around waiting for something
- external to happen. I ran into this same sort of thing happening when I
- did a port of NCSA's tcp to run under windows (this was a couple of years
- ago, and not very successful). Another, related, possibility has to do
- with the way background dispatching priorities are set up under Windows.
- Keep in mind that TCPMAN is an .exe, not a .dll, and is subject to
- background/foreground priorities. Since the tcp application has the
- focus, TCPMAN is always (I assume) subject to the background priority.
- I intend to look into this area further myself at the first opportunity.
- Any thoughts?
-
- Tim Gauslin
- Visual Technology Products
-
-